문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 CPU 게이트 (문단 편집) === 스펙터 === 한편 '''스펙터'''(또는 스펙터 익스플로잇)는 멜트다운 버그와 비슷하게 추측 실행(speculative execution)으로 인해 일어나기는 하지만, ''조금 덜'' 심각하다. 하지만 그렇다 해도 심각한 건 마찬가지이다. 가장 원초적이면서 가장 기본이 되는 가장 깊은 곳에서, 절대로 남이 봐서는 안되는 정보가 해킹될 수 있기 때문. 또한 후술하다시피 스펙터는 구현하기가 어렵지만, 기어코 구현되고 나면 발견하는 것은 물론, 발견하더라도 막는 것도 그만큼 어렵다. 스펙터는 추측 실행을 할 때 다른 곳의 코드 실행[* 함수 호출 뿐 아니라 더 일반적으로 {{{jmp}}}와 같은 점프를 뜻한다.](분기표적 주입(branch target injection)의 경우)이나 조건문(경계검사 우회(bounds check bypass)의 경우)을 실행한 뒤 잘못된 경우에 취소시키는데, 이때 비슷한 부작용이 발생하는 점을 악용하여 다른 프로그램의 메모리를 읽어들이는 것이다. 다만 메모리를 훔쳐볼 수만 있고 메모리에 기록할 수는 없으므로 그 자체만으로 직접 시스템에 파괴적인 행동을 하거나 [[랜섬웨어]] 등 악성코드를 심는 것은 불가능하다. 또한 커널 영역 메모리에 접근 가능한 것은 아니므로 상대적으로 멜트다운보다는 시스템에 끼치는 영향은 좀 더 적을 것으로 보인다. 하지만 다른 프로세스의 메모리에 올라온 모든 정보를 해커가 읽을 수 있는 이상, 직접 각종 개인정보를 유출하여 이메일, 검색포털, 스팀, 배틀넷 등의 계정을 탈취하거나, 최악의 경우 은행 공동인증서 비밀번호와 기타 온라인 뱅킹 전자서명까지 죄다 털리고 현금이 인출되는 상황이 벌어지거나 하는 일이 벌어질 가능성은 있다. 게다가 이러한 일련의 공격을 막기 위해 데이터를 암호화하는 것도, 그 암호의 복호화 키가 메모리에 있는 한 키 역시 같이 유출될테니 근본적인 해결책이 되지 않으며, 상술했듯이 공격을 수행하는 것 자체를 막는 것도 악성코드의 소행인지를 판단하기 어렵기 때문에 어려운 것도 문제다. 스펙터 버그의 경우 유저들의 프로그램간 메모리 스니핑이 일어나는 거긴 하지만, 기본적으로 '''대상 프로그램에서 문제가 존재하는 코드의 추측 실행이 되어야 하기 때문에''', 실제 버그를 이용해 공격하려면 공격하려는 대상 프로그램을 세세하게 분석해야 되고, 프로그램이 돌아가는 CPU 아키텍처나 운영 체제에 대해서도 자세히 알아야 되고, 실제로는 취약점을 공격하긴 매우 어렵다. 그래서 현재까지 실질적으로 해당 취약점의 영향을 받는 곳은 런타임에 [[JIT]] 컴파일러에 의존하는 자바스크립트 엔진과 그 웹브라우저들 뿐이다. 단, 어느 코드에서나 문제가 존재할 가능성이 있기 때문에, 문제를 발견해 막기도 힘들다(그래서 이름이 [[유령]], Spectre이다.). 예를 들어 [[프로젝트 제로]]측에서는 '''리눅스 커널 상에서 실행되는''' 패킷 필터 [[JIT]] [[컴파일러]]를 이용해 문제가 되는 코드를 커널 컨텍스트상에서 만들어 실행시켰다. 그래서 스펙터의 경우 긴급 보안 패치는 난이도를 훨씬 더 어렵게 만들어 놓은 것이다. 문제는 '''스펙터 취약점 또한 하드웨어 구조적 결함이라 업데이트같은 소프트웨어적 미봉책으로는 사실상 완전히 막을 수 없다'''는 것이다. 스펙터 버그의 공동 발견자 중 한 명인 폴 코처(Paul Kocher)에 [[https://www.nytimes.com/2018/01/03/business/computer-flaws.html|따르면]], 스펙터 버그가 소프트웨어 패치로 해결되지 않는다고 한다. 멜트다운 버그가 긴급한 위기인 반면, 스펙터 버그는 모든 고성능 프로세서에 영향을 끼칠 수 있으며, 성능에 중점을 둔 설계가 이러한 버그에 취약하게 만들었다고 한다. 즉, 성능과 보안을 모두 얻으려던 업계의 갈망이 불가능하다는 것을 보여주는 사례가 스펙터 버그이며 새로운 설계의 프로세서가 나오기 전까지 존재할 것이라고 한다. 스펙터 버그는 수십년간 사용된 프로세서 설계에 존재하는 결함이기 때문이다. 스펙터 버그는 멜트다운 버그에 비해 심각성이 적다고 여겨지지만, 현대의 고성능 CPU 중에 스펙터 버그에 면역인 CPU가 존재하지 않고, 면역이 되기 위해서는 성능을 포기해야 하며, [[http://www.coolenjoy.net/bbs/38/1432901|어느 정도로 위험한지는 감도 안 잡히는 상황이고, 현재 상황으론 얼마나 완화될 수 있는지도 미지수인데]] 근본적인 해결법은 새로운 설계의 CPU 밖에 없어, 가볍게 여겨져서는 안될 것으로 보인다. 2019년 2월 Ars Technica [[https://arstechnica.com/gadgets/2019/02/google-software-is-never-going-to-be-able-to-fix-spectre-type-bugs/|기사]]에 따르면 현 시점에서 스펙터 버그는 추측 실행을 포기하지 않는 이상 완전히 막을 수 없는 것으로 여겨지고 있다. 스펙터 버그를 이용해 메모리 구조를 파악하게 되면 해당 구조에 맞는 다른 취약점을 통해 임의의 코드를 성공적으로 실행할 수 있을 가능성이 높아지기에 이 취약점과 관련된 문제들이 지속될 것으로 예상된다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기